Thank you for your contribution!

I did some research and it seems that if we implement such a function independently in arf, it may cause inconsistencies with the internal state of reedline.
I think we should add a new feature to reedline. What do you think?

Seems reasonable to me! I'll take a look. Thanks for your work on this, huge fan!

Thanks!

It might be a good idea to add an argument to Painter::initialize_prompt_position.
It already calls cursor::position() and sets prompt_start_row, so adding a margin check there would keep everything consistent with reedline's internal state.

So I tried implementing the bottom margin in reedline here per your suggestion about Painter::initialize_prompt_position. I used a field on Painter rather than a separate argument (small implementation difference, same concept).
It works for initial placement, but reedline ends up hopping around and erasing R output since it isn't aware of when R prints.

I'm not seeing another approach beyond the current one that maintains reedline's state consistency while handling external output. Do you see something I'm missing?

Sidenote, I think bottom_buffer_fraction would be better named bottom_margin with typed config for clarity. It would result in a config option in this format:

[prompt]
bottom_margin = { type = "proportional", value = 0.5 }

or

[prompt]
bottom_margin = { type = "fixed", value = 10 }

Thanks for trying the reedline approach and sharing the results!

I looked into Painter internals and I agree repaint_buffer has its own scrolling logic and is_reset() checks that conflict with scrolling in initialize_prompt_position.
Doing it outside reedline before read_line() seems more practical.

That said, I have some feedback on the current implementation:

• ScrollUp(1) in a loop should be ScrollUp(lines_to_scroll)
• fraction <= 0.0 early-returns (disables the feature), but the doc says 0.0 means "top of screen". These are contradictory.
• cursor::position() involves terminal I/O (query + response). Calling it every REPL iteration could be noticeable.
• [prompt] section is for format strings and indicators. Screen positioning feels like it belongs in [editor] or a new section.
• No tests for the scroll behavior. This project has PTY-based integration tests (using vt100 + portable-pty) that can verify cursor positioning and screen state, so a test like that would be needed here. Let me know if that's difficult to add, I can help.

Okay I made those changes, cleaned up the config format a bit, and attempted to do some PTY tests. Also updated the PR title and initial description comment

The only thing I didn't address is this point:

cursor::position() involves terminal I/O (query + response). Calling it every REPL iteration could be noticeable.

That is still the case but I think this is an inherent tradeoff if we don't want the prompt line to drift at all. If some drift were tolerable then I guess some kind of 'every X iteration' would be possible but I don't think that would be the ideal UX. I personally think the 2-5ms per prompt is acceptable as long as it stays an opt-in feature.